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Abstract 
A frame relay pseudowire is a mechanism that exists between a 
provider’s edge network nodes and that supports as faithfully as 
possible frame relay services over an MPLS packet switched network 


(PSN). This document describes the detailed encapsulation necessary 
to transport frame relay packets over an MPLS network. 
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dT Introduction 


In an MPLS or IP network, it is possible to use control protocols 
such as those specified in [RFC4447] to set up "pseudowires" (PWs) 
that carry the Protocol Data Units of layer 2 protocols across the 
network. A number of these emulated PWs may be carried in a single 
tunnel. The main functions required to support frame relay PW by a 
Provider Edge (PE) include: 


- encapsulation of frame relay specific information in a suitable 
pseudowire (PW) packet; 


- transfer of a PW packet across an MPLS network for delivery to a 
peer PE; 


- extraction of frame relay specific information from a PW packet by 
the remote peer PE; 
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- regeneration of native frame relay frames for forwarding across an 
egress port of the remote peer PE; and 


- execution of any other operations as required to support frame 
relay service. 


This document specifies the encapsulation for the emulated frame 
relay VC over an MPLS PSN. Although different layer 2 protocols 
require different information to be carried in this encapsulation, an 
attempt has been made to make the encapsulation as common as possible 
for all layer 2 protocols. Other layer 2 protocols are described in 
separate documents. [ATM] [RFC4448] [RFC4618] 


The following figure describes the reference models that are derived 
from [RFC3985] to support the frame relay PW emulated services. 


aa E aa EMULated Service ‘SS -ss sree -as > > 
LS Pseudowire =-=-=-= > 


| 
| 
| | 
| | 
| |<-- PSN Tunnel -->| | 
PW End V v v V PW End | 
+ V 

| 


V Service ----+ +----+ Service 
+----- + | PE1 | | PE2 | | +----- + 
| aa PW1......----+--|-------- | 
| CE1 | | | | | | | | CE2 | 
| a PWS so theta ests | ---------- | | 
tot | O e cee. 
a <) +----+ +----+ EE 
| | Provider Edge 1 Provider Edge 2 | 
| | (PE1) (PE2) l et 
Customer | | Customer 
Edge 1 | | Edge 2 
Attachment Circuit (AC) Attachment Circuit (AC) 
native frame relay service native frame relay service 
Figure 1. PWE3 frame relay PVC interface reference configuration 


Two mapping modes can be defined between frame relay VCs and 
pseudowires: The first one is called "one-to-one" mapping, because 
there is a one-to-one correspondence between a frame relay VC and one 


pseudowire. The second mapping is called "many-to-one" mapping or 
"port mode" because multiple frame relay VCs assigned to a port are 
mapped to one pseudowire. The "port mode" encapsulation is identical 


to High-Level Data Link Control (HDLC) pseudowire encapsulation, 
which is described in [RFC4618]. 
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2g 


Specification of Requirements 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119. 
Below are the definitions for the terms used throughout the document. 
PWE3 definitions can be found in [RFC3916, RFC3985]. This section 
defines terms specific to frame relay. 


- Forward direction 


The forward direction is the direction taken by the frame being 
forwarded. 


— Backward direction 


In frame relay, it is the direction opposite to the direction taken 
by a frame being forwarded (see also forward direction). 
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4. Acronyms and Abbreviations 


BECN Backward Explicit Congestion Notification 
CE Customer Edge 

C/R Command/Response 

DE Discard Eligibility 

DLCI Data Link Connection Identifier 
FCS Frame Check Sequence 

FECN Forward Explicit Congestion Notification 
FR Frame Relay 

LSP Label Switched Path 

LSR Label Switching Router 

MPLS Multiprotocol Label Switching 

MTU Maximum Transfer Unit 

NNI Network-Network Interface 

PE Provider Edge 

PSN Packet Switched Network 

PW Pseudowire 

PWE3 Pseudowire Emulation Edge to Edge 
POS Packet over SONET/SDH 

PVC Permanent Virtual Circuit 

Qos Quality of Service 

SVC Switched Virtual Circuit 

UNI User-Network Interface 

VC Virtual Circuit 


5. Applicability Statement 


Frame relay over PW service is not intended to emulate the 
traditional frame relay service perfectly, but it can be used for 
applications that need frame relay transport service. 


The following are notable differences between traditional frame relay 
service and the protocol described in this document: 


- Frame ordering can be preserved using the OPTIONAL sequence field 
in the control word; however, implementations are not required to 


support this feature. 


- The Quality of Service model for traditional frame relay can be 
emulated; however, this is outside the scope of this document. 


- A Frame relay port mode PW does not process any frame relay status 
messages or alarms as described in [Q922] [Q933] 


- The frame relay BECN and FECN bit are transparent to the MPLS 
network and cannot reflect the status of the MPLS network. 
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— Support for frame relay SVC and Switched Permanent Virtual Circuit 
(SPVC) is outside the scope of this document. 


- Frame relay Local Management Interface (LMI) is terminated locally 
in the PE connected to the frame relay attachment circuit. 


-— The support of PVC link integrity check is outside the scope of 
this document. 


6. General Encapsulation Method 
The general frame relay pseudowire packet format for carrying frame 


relay information (user’s payload and frame relay control 
information) between two PES is shown in Figure 2. 


| MPLS Transport header | 
| (As required) | 


4+------------------------------- + 
| Pseudowire (PW) Header | 
4+------------------------------- + 
| Control Word | 
+------------------------------- + 
| FR Service | 
| Payload | 
4+------------------------------- + 
Figure 2. General format of frame relay encapsulation over PSN 


The PW packet consists of the following fields: Control word and 
Payload, preceded by the MPLS Transport and pseudowire header. The 
meaning of the different fields is as follows: 


=i. MPLS Transport header is specific to the MPLS network. This 
header is used to switch the PW packet through the MPLS core. 


SEI PW header contains an identifier for multiplexing PWs within 
an MPLS tunnel. 


-iii. Control Word contains protocol control information for 
providing a frame relay service. Its structure is provided in 
the following sections. 


-iv. The content of the frame relay service payload field depends 


on the mapping mode. In general it contains the layer 2 frame 
relay frame. 
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7. Frame Relay over MPLS PSN for the One-to-One Mode 

7.1. MPLS PSN Tunnel and PW 
MPLS label switched paths (LSPs) called "MPLS Tunnels" are used 
between PEs and are used within the MPLS core network to forward PW 
packets. An MPLS tunnel corresponds to "PSN Tunnel" of Figure 1. 
Several PWs may be nested inside one MPLS tunnel. Each PW carries 
the traffic of a single frame relay VC. In this case, the PW header 
is an MPLS label called the PW label. 

7.2. Packet Format over MPLS PSN 


For the one-to-one mapping mode for frame relay over an MPLS network, 
the PW packet format is as shown in Figure 3. 


5 Sas cea cal pea a mn oes cn ges + 

| MPLS Tunnel label(s) | n*4 octets (four octets per label) 
eS SSS SSS SHS Sse SS se SSeS Sse= + 

| PW label | 4 octets 
SNARARE cai eC eaten a + 

| Control Word | 

| (See Figure 4) | 4 octets 
pr ene H a + 

| Payload | 

| (Frame relay frame | 

information field) n octets 

Fn + 


Figure 3. Frame Relay over MPLS PSN Packet for the 
One-to-One Mapping 


The meaning of the different fields is as follows: 
- MPLS Tunnel label(s) 


The MPLS Tunnel label(s) corresponds to the MPLS transport header 
of Figure 2. The label(s) is/are used by MPLS LSRs to forward a PW 
packet from one PE to the other. 


- PW Label 


The PW label identifies one PW (i.e., one LSP) assigned to a frame 
relay VC in one direction. It corresponds to the PW header of 
Figure 2. Together the MPLS Tunnel label(s) and PW label form an 
MPLS label stack [RFC3032]. 
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— Control Word 


The Control Word contains protocol control information. Its 
structure is shown in Figure 4. 


- Payload 


The payload field corresponds to X.36/X.76 frame relay frame 
information field with the following components removed: bit/byte 
stuffing, frame relay header, and FCS. It is RECOMMENDED to 
support a frame size of at least 1600 bytes. The maximum length of 
the payload field MUST be agreed upon by the two PEs. This can be 
achieved by using the MTU interface parameter when the PW is 
established. [RFC4447] 


7.3. The Control Word 


The control word defined below is REQUIRED for frame relay one-to-one 
mode. The control word carries certain frame relay specific 
information that is necessary to regenerate the frame relay frame on 
the egress PE. Additionally, the control word also carries a 
sequence number that can be used to preserve sequentiality when 


carrying frame relay over an MPLS network. Its structure is as 
follows: 
0 1 2 3 


0123456789012345678°9012345678901 
Pata t ata tata ta tatar tata tata tata aa 
|o 0 0 OljF|B|D|C|FRG| Length | Sequence Number 
Pata t ata tat ata t tata tata tat tata tata tata tata tata tat 


Figure 4. Control Word structure for the one-to-one mapping mode 


The meaning of the Control Word fields (Figure 4) is as follows (see 
also [X36 and X76] for frame relay bits): 


- Bits 0 to 3 


In the above diagram, the first 4 bits MUST be set to 0 to 
indicate PW data. 


- F (bit 4) FR FECN (Forward Explicit Congestion Notification) bit. 
- B (bit 5) FR BECN (Backward Explicit Congestion Notification) bit. 
- D (bit 6) FR DE bit (Discard Eligibility) bit. 


- C (bit 7) FR frame C/R (Command/Response) bit. 


Martini & Kawa Standards Track [Page 8] 


RFC 4619 Encapsulation for Transport of Frame Relay September 2006 


- FRG (bits 8 and 9): These bits are defined by [RFC4623]. 
- Length (bits 10 to 15) 


If the PW traverses a network link that requires a minimum frame 
size (a notable example is Ethernet), padding is required to reach 
its minimum frame size. If the frame’s length (defined as the 
length of the layer 2 payload plus the length of the control word) 
is less than 64 octets, the length field MUST be set to the PW 
payload length. Otherwise, the length field MUST be set to zero. 
The value of the length field, if non-zero, is used to remove the 
padding characters by the egress PE. 


- Sequence number (Bit 16 to 31) 


Sequence numbers provide one possible mechanism to ensure the 


ordered delivery of PW packets. The processing of the sequence 
number field is OPTIONAL. The sequence number space is a 16-bit 
unsigned circular space. The sequence number value 0 is used to 


indicate that the sequence number check algorithm is not used. 
7.4. The Martini Legacy Mode Control Word 


For backward compatibility to existing implementations, the following 
version of the control word is defined as the "martini mode CW" for 
frame relay. 


0 1 2 3 
OL -2°3-4-9 6 7 8°90 12:34 56.7738 9 0-12 3:4 36° 7 89-0 1 
Fata a TE tata tata tata tata E tata tata tata tata tatatat 
|o 0 0 O|B\F|D|C|FRG| Length | Sequence Number 
Fata t ata tata ta tat tata tata tata DE A tata tata tata totatat 


Figure 5. Control Word structure for the frame relay martini mode 
Note that the "B" and "F" bits are reversed. 


This control word format is used for PW type "Frame Relay DLCI ( 
Martini Mode )" 


7.5. PW Packet Processing 
7.5.1. Encapsulation of Frame Relay Frames 
The encapsulation process of a frame relay frame is initiated when a 


PE receives a frame relay frame from one of its frame relay UNI or 
NNI [FRF1] [FRF2] interfaces. The PE generates the following fields 
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of the control word from the corresponding fields of the frame relay 
frame as follows: 


- Command/Response (C/R or C) bit: The C bit is copied unchanged in 
the PW Control Word. 


- The DE bit of the frame relay frame is copied into the D bit field. 
However, if the D bit is not already set, it MAY be set as a result 
of ingress frame policing. If it is not already set by the copy 
operation, setting of this bit by a PE is OPTIONAL. The PE MUST 
NOT clear this bit (set it to 0 if it was received with the value 
of 1). 


— The FECN bit of the frame relay frame is copied into the F bit 
field. However, if the F bit is not already set, it MAY be set to 
reflect a congestion situation detected by the PE. If it is not 
already set by the copy operation, setting of this bit by a PE is 
OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was 
received with the value of 1) 


-— The BECN bit of the frame relay frame is copied into the B bit 
field. However, if the B bit is not already set, it MAY be set to 
reflect a congestion situation detected by the PE. If it is not 
already set by the copy operation, setting of this bit by a PE is 
OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was 
received with the value of 1). 


- If the PW packet length (defined as the length of the payload plus 
the length of the control word) is less than 64 octets, the length 
field MUST be set to the packet’s length. Otherwise, the length 
field MUST be set to zero. 


-— The sequence number field is processed if the PW uses sequence 
numbers. [RFC4385] 


- The payload of the PW packet is the contents of ITU-T 
Recommendations X.36/X.76 [X36] [X76] frame relay frame information 
field stripped from any bit or byte stuffing. 

7.5.2. Setting the Sequence Number 
For a given PW and a pair of routers PE1 and PE2, if PE1 supports 


packet sequencing, then the procedures in [RFC4385], Section 4.1, 
MUST be followed. 
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7.6. Decapsulation of PW Packets 


When a PE receives a PW packet, it processes the different fields of 
the control word in order to decapsulate the frame relay frame for 
transmission to a CE on a frame relay UNI or NNI. The PE performs 
the following actions (not necessarily in the order shown): 


- It generates the following frame relay frame header fields from the 
corresponding fields of the PW packet. 


— The C/R bit MUST be copied in the frame relay header. 
- The D bit MUST be copied into the frame relay header DE bit. 


- The F bit MUST be copied into the frame relay header FECN bit. If 
the F bit is set to zero, the FECN bit may be set to one, depending 
on the congestion state of the PE device in the forward direction. 
Changing the state of this bit by a PE is OPTIONAL. 


- The B bit MUST be copied into the frame relay header BECN bit. If 
the B bit is set to zero, the BECN bit may be set to one, depending 
on the congestion state of the PE device in the backward direction. 
Changing the state of this bit by a PE is OPTIONAL. 


- It processes the length and sequence field, the details of which 
are in the following sub-sections. 


- It copies the frame relay information field from the contents of 
the PW packet payload after removing any padding. 


Once the above fields of a FR frame have been processed, the standard 
HDLC operations are performed on the frame relay frame: the HDLC 
header is added, any bit or byte stuffing is added as required, and 
the FCS is also appended to the frame. The FR frame is then queued 
for transmission on the selected frame relay UNI or NNI interface. 


7.6.1. Processing the Sequence Number 


If a router PE2 supports received sequence number processing, then 
the procedures in [RFC4385], Section 4.2, MUST be used. 


7.6.2. Processing of the Length Field by the Receiver 


Any padding octet, if present, in the payload field of a PW packet 
received MUST be removed before forwarding the data. 


- If the Length field is set to zero, then there are no padding 
octets following the payload field. 


Martini & Kawa Standards Track [Page 11] 


RFC 4619 Encapsulation for Transport of Frame Relay September 2006 


- Otherwise, if the payload is longer, then the length specified in 
the control word padding characters are removed according to the 
length field. 


7.7. MPLS Shim EXP Bit Values 


If it is desired to carry Quality of Service information, the Quality 
of Service information SHOULD be represented in the Experimental Use 
Bits (EXP) field of the PW MPLS label [RFC3032]. If more than one 
MPLS label is imposed by the ingress LSR, the EXP field of any labels 
higher in the stack SHOULD also carry the same value. 


7.8. MPLS Shim S Bit Value 


The ingress LSR, PE1, MUST set the S bit of the PW label to a value 
of 1 to denote that the PW label is at the bottom of the stack. 


7.9. Control Plane Details for Frame Relay Service 


The PE MUST provide frame relay PVC status signaling to the frame 
relay network. If the PE detects a service-affecting condition for a 
particular DLCI, as defined in [0933] 9.933, Annex A.5, sited in IA 
FRF1.1, the PE MUST communicate to the remote PE the status of the PW 
that corresponds to the frame relay DLCI status. The Egress PE 
SHOULD generate the corresponding errors and alarms as defined in 
[Q922] [Q933] on the egress Frame relay PVC. 


There are two frame relay flags to control word bit mappings 
described below. The legacy bit ordering scheme will be used for a 
PW of type 0x0001, "Frame Relay DLCI (Martini Mode)", and the new bit 
ordering scheme will be used for a PW of type 0x0019, "Frame Relay 
DLCI". The IANA allocation registry of "Pseudowire Type" is defined 
in [RFC4446] along with initial allocated values. 


7.9.1. Frame Relay Specific Interface Parameter Sub-TLV 


A separate document, [RFC4447], describes the PW control and 
maintenance protocol in detail, including generic interface parameter 
sub-TLVs. The interface parameter information, when applicable, MUST 
be used to validate that the PEs and the ingress and egress ports at 
the edges of the circuit have the necessary capabilities to 
interoperate with each other. The Interface parameter TLV is defined 
in [RFC4447], and the IANA registry with initial values for interface 
parameter sub-TLV types is defined in [RFC4446], but the frame relay 
specific interface parameter sub-TLV types are specified as follows: 


- 0x08 Frame Relay Header Length Sub-TLV 
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An optional 16-bit value indicating the length of the FR Header, 
expressed in octets. This OPTIONAL interface parameter Sub-TLV can 
have value of 2, 3, or 4, the default being 2. If this Sub-TLV is 
not present, the default value of 2 is assumed. 


8. Frame Relay Port Mode 


The frame relay port mode PW shares the same encapsulation as the 
HDLC PW and is described in the respective document. [RFC4618] 


9. Congestion Control 


As explained in [RFC3985], the PSN carrying the PW may be subject to 
congestion, the characteristics of which depend on PSN type, network 
architecture, configuration, and loading. During congestion, the PSN 
may exhibit packet loss that will impact the service carried by the 
frame relay PW. In addition, since frame relay PWs carry a variety 
of services across the PSN, including but not restricted to TCP/IP, 
they may or may not behave in a TCP-friendly manner prescribed by 
[RFC2914]. In the presence of services that reduce transmission 
rate, frame relay PWs may thus consume more than their fair share and 
in that case SHOULD be halted. 


Whenever possible, frame relay PWs should be run over traffic- 
engineered PSNs providing bandwidth allocation and admission control 
mechanisms. IntServ-enabled domains providing the Guaranteed Service 
(GS) or DiffServ-enabled domains using EF (expedited forwarding) are 
examples of traffic-engineered PSNs. Such PSNs will minimize loss 
and delay while providing some degree of isolation of the frame relay 
PW’s effects from neighboring streams. 


Note that when transporting frame relay, DiffServ-enabled domains may 
use AF (Assured Forwarding) and/or DF (Default Forwarding) instead of 
EF, in order to place less burden on the network and to gain 
additional statistical multiplexing advantage. In particular, if the 
Committed Information Rate (CIR) of a frame relay VC is zero, then it 
is equivalent to a best-effort UDP over IP stream regarding 
congestion: the network is free to drop frames as necessary. In 
this case, the "DF" Per Hop Behavior (PHB) would be appropriate in a 
diff-serv-TE domain. Alternatively, if the CIR of a frame relay VC 
is nonzero and the DE bit is zero in the FR header, then "AF31" would 
be appropriate to be used, and if the CIR of a frame relay VC is 
nonzero but the DE bit is on, then "AF32" would be appropriate 
[RFC3270]. 


The PEs SHOULD monitor for congestion (by using explicit congestion 


notification, [VCCV], or by measuring packet loss) in order to ensure 
that the service using the frame relay PW may be maintained. When a 
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PE detects significant congestion while receiving the PW PDUs, the 
BECN bits of the frame relay frame transmitted on the same PW SHOULD 
be set to notify the remote PE and the remote frame relay switch of 
the congestion situation. In addition, the FECN bits SHOULD be set 
in the FR frames sent out the attachment circuit, to give the FR DTE 
a chance to adjust its transport layer advertised window, if 
possible. 


If the PW has been set up using the protocol defined in [RFC4447], 
then procedures specified in [RFC4447] for status notification can be 
used to disable packet transmission on the ingress PE from the egress 
PE. The PW may be restarted by manual intervention, or by automatic 
means after an appropriate waiting time. 


10. Security Considerations 


PWE3 provides no means of protecting the contents or delivery of the 
PW packets on behalf of the native service. PWE3 may, however, 
leverage security mechanisms provided by the MPLS Tunnel Layer. A 
more detailed discussion of PW security is given in [RFC3985, 
RFC4447, RFC3916]. 
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